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Client-Side Boot Domains and Boot Rules 

TECHNICAL FIELD 

This invention relates generally to computer operating systems, and more 
5 particularly to verifying components loaded by an operating system. 

BACKGROUND OF THE INVENTION 

More and more content is being delivered in digital form, and more and 

more digital content is being delivered online over private and public networks, 
10 such as Intranets, the Internet and cable TV networks. For a client, digital form 
allows more sophisticated content, while online delivery improves timeliness and 
convenience. For a publisher, digital content also reduces delivery costs. 
Unfortunately, these worthwhile attributes are often outweighed in the minds of 
publishers by the corresponding disadvantage that online information delivery 
15 makes it relatively easy to obtain pristine digital content and to pirate the content at 
the expense and harm of the publisher. 

To prevent their content from being stolen or misused, content providers will 
download content only to trusted software, and therefore only to subscriber 
computers that can prove that the software executing on the subscriber computer is 
20 trusted. This trust concept is predicated on having a trusted operating system 
executing on the computer, which, by its nature, only loads trusted components and 
provides some kind of secure storage. The problem then becomes one of 
identifying an operating system with such peculiarity that the content provider can 
make an intelligent decision whether to trust its content to the operating system. 
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The related application titled "System and Method for Authenticating an 
Operating System to a Central Processing Unit, Providing the CPU/OS with Secure 
Storage, and Authenticating the CPU/OS to a Third Party" discloses one 
embodiment of a unique operating system identifier that is a cryptographic digest of 
5 all the software components loaded by the operating system. However, computers 
contain a myriad different hardware components, and the corresponding supporting 
software components are frequently updated to add enhancements and fix problems, 
resulting in a virtually unlimited number of operating system identities. While the 
content provider can maintain a list of those identities it trusts, or delegate the 
10 maintenance of such a list to a third-party, what is needed in the art is a way to 
reduce the number of trusted operating system identities without limiting the 
choices of software components available to a user. 

SUMMARY OF THF INVENTION 

The above-mentioned shortcomings, disadvantages and problems are 

15 addressed by the present invention, which will be understood by reading and 
studying the following specification. 

Each software component loaded for a verified operating system on a client 
computer must satisfy a set of boot rules for a boot certificate. The appropriate boot 
certificate is selected by the user or by default upon each boot of the computer. A 

20 verified operating system identifier is created from the boot certificate. The boot 
certificate is published and signed by a boot authority that attests to the validity of 
the operating system booted under the boot certificate. Each software component 
for the operating system is associated with a component certificate published and 
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signed by the same boot authority that signed the boot certificate. The boot rules 
determine the validity of the software component based on the contents of the 
component and boot certificates. 

The client computer transmits the verified operating system identity and the 
5 boot certificate to a server computer, such as a content provider, and the content 
provider determines whether to trust the verified operating system with its content. 
Downloaded data is secured on permanent storage through a key derived from the 
verified operating system identifier. The boot certificate, component certificates, 
and secured content define the boot domain. 

10 A combination of two or more boot components can be used to boot a 

verified operating system. Updating of the boot and component certificates, the 
underlying components, and the changing of the verified operating system identity 
and its affect on the boot domain are also described. 

Because a content provider must only decide which boot authorities, and 

15 which boot certificates from those authorities, to trust, the content provider must 
keep track of only a small number of identities. The client computer is restricted 
only in that components loaded into a verified operating system must be attested to 
by one of the boot authorities trusted by the content provider. The client computer 
can operate under an unverified operating system but data stored under a verified 

20 boot domain will not be accessible. 

The present invention describes systems, clients, servers, methods, and 
computer-readable media of varying scope. In addition to the aspects and 
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advantages of the present invention described in this summary, further aspects and 
advantages of the invention will become apparent by reference to the drawings and 
by reading the detailed description that follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 FIG. 1A is a diagram of the hardware and operating environment in 

conjunction with which embodiments of the invention may be practiced; 

FIG. IB is a diagram of a client computer for use with exemplary 
embodiments of the invention; 

FIG. 2 is a diagram illustrating a system-level overview of an exemplary 
1 0 embodiment of the invention; 

FIG. 3 is a time line diagram illustrating interactions between boot and 
component certificates used the exemplary embodiment of the invention shown in 
FIG. 2; 

FIG. 4 is a flowchart of a method to be performed by a client when booting 
15 according to an exemplary embodiment of the invention; 

FIG. 5 is a flowchart of a method to be performed by a client in obtaining a 
new component certificate according to an exemplary embodiment of the invention; 

FIG. 6 is a flowchart of a method to be performed by a client in obtaining an 
updated component certificate to an exemplary embodiment of the invention; 
20 FIGs. 7A and 7B are flowcharts of a method to be performed by a client in 

obtaining downloaded content according to an exemplary embodiment of the 
invention; 
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FIG. 8A is a diagram of a boot certificate data structure for use in an 
exemplary implementation of the invention; 

FIG. 8B is a diagram of an entry in a revocation list data structure for use in 
an exemplary implementation of the invention; 
5 FIG. 9 is a diagram of a component certificate data structure for use in an 

exemplary implementation of the invention; and 

FIG. 10 is a diagram of an time certificate data structure for use in an 
exemplary implementation of the invention. 

DETA TT.FD DES CRIPTION OF THE PREFERRED EMBODIMENT 

10 In the following detailed description of exemplary embodiments of the 

invention, reference is made to the accompanying drawings which form a part 
hereof, and in which is shown by way of illustration specific exemplary 
embodiments in which the invention may be practiced. These embodiments are 
described in sufficient detail to enable those skilled in the art to practice the 
15 invention, and it is to be understood that other embodiments may be utilized and 
that logical, mechanical, electrical and other changes may be made without 
departing from the spirit or scope of the present invention. The following detailed 
description is, therefore, not to be taken in a limiting sense. 

The detailed description is divided into five sections. In the first section, the 
20 hardware and the operating environment in conjunction with which embodiments of 
the invention may be practiced are described. In the second section, a system level 
overview of the invention is presented. In the third section, methods for an 
exemplary embodiment of the invention are provided. In the fourth section, a 
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particular implementation of the invention is described for use with the Microsoft 
Corporation "WINDOWS" family of operating system. Finally in the fifth section, 
a conclusion of the detailed description is provided. 

5 Hardware and Operating Environment 

FIG. 1A is a diagram of the hardware and operating environment in 
conjunction with which embodiments of the invention may be practiced. The 
description of FIG. 1A is intended to provide a brief, general description of suitable 
computer hardware and a suitable computing environment in conjunction with 

10 which the invention may be implemented. Although not required, the invention is 
described in the general context of computer-executable instructions, such as 
program modules, being executed by a computer, such as a personal computer. 
Generally, program modules include routines, programs, objects, components, data 
structures, etc., that perform particular tasks or implement particular abstract data 

15 types. 

Moreover, those skilled in the art will appreciate that the invention may be 
practiced with other computer system configurations, including hand-held devices, 
multiprocessor systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe computers, and the like. The 
20 invention may also be practiced in distributed computing environments where tasks 
are performed by remote processing devices that are linked through a 
communications network. In a distributed computing environment, program 
modules may be located in both local and remote memory storage devices. 
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The exemplary hardware and operating environment of FIG. 1A for 
implementing the invention includes a general purpose computing device in the 
form of a computer 20, including a processing unit 21, a system memory 22, and a 
system bus 23 that operatively couples various system components include the 
5 system memory to the processing unit 21 . There may be only one or there may be 
more than one processing unit 21, such that the processor of computer 20 comprises 
a single central-processing unit (CPU), or a plurality of processing units, commonly 
referred to as a parallel processing environment. The computer 20 may be a 
conventional computer, a distributed computer, or any other type of computer; the 

10 invention is not so limited. 

The system bus 23 may be any of several types of bus structures including a 
memory bus or memory controller, a peripheral bus, and a local bus using any of a 
variety of bus architectures. The system memory may also be referred to as simply 
the memory, and includes read only memory (ROM) 24 and random access memory 

15 (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines 
that help to transfer information between elements within the computer 20, such as 
during start-up, is stored in ROM 24. The computer 20 further includes a hard disk 
drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk 
drive 28 for reading from or writing to a removable magnetic disk 29, and an 

20 optical disk drive 30 for reading from or writing to a removable optical disk 31 such 
as a CD ROM or other optical media. 



WO 01/42889 PCT/USOO/42678 

8 

The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are 
connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk 
drive interface 33, and an optical disk drive interface 34, respectively. The drives 
and their associated computer-readable media provide nonvolatile storage of 
5 computer-readable instructions, data structures, program modules and other data for 
the computer 20. It should be appreciated by those skilled in the art that any type of 
computer-readable media which can store data that is accessible by a computer, 
such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli 
cartridges, random access memories (RAMs), read only memories (ROMs), and the 
1 0 like, may be used in the exemplary operating environment. 

A number of program modules may be stored on the hard disk, magnetic disk 
29, optical disk 31, ROM 24, or RAM 25, including an operating system 35, one or 
more application programs 36, other program modules 37, and program data 38. A 
user may enter commands and information into the personal computer 20 through 
15 input devices such as a keyboard 40 and pointing device 42. Other input devices 
(not shown) may include a microphone, joystick, game pad, satellite dish, scanner, 
or the like. These and other input devices are often connected to the processing unit 
21 through a serial port interface 46 that is coupled to the system bus, but may be 
connected by other interfaces, such as a parallel port, game port, or a universal 
20 serial bus (USB). A monitor 47 or other type of display device is also connected to 
the system bus 23 via an interface, such as a video adapter 48. In addition to the 



WO 01/42889 PCT/US00/42678 

9 

monitor, computers typically include other peripheral output devices (not shown), 
such as speakers and printers. 

The computer 20 may operate in a networked environment using logical 
connections to one or more remote computers, such as remote computer 49. These 
5 logical connections are achieved by a communication device coupled to or a part of 
the computer 20; the invention is not limited to a particular type of communications 
device. The remote computer 49 may be another computer, a server, a router, a 
network PC, a client, a peer device or other common network node, and typically 
includes many or all of the elements described above relative to the computer 20, 

10 although only a memory storage device 50 has been illustrated in FIG. 1. The 
logical connections depicted in FIG. 1A include a local-area network (LAN) 51 and 
a wide-area network (WAN) 52. Such networking environments are commonplace 
in offices, enterprise-wide computer networks, intranets and the Internet. 

When used in a LAN-networking environment, the computer 20 is connected 

15 to the local network 5 1 through a network interface or adapter 53, which is one type 
of communications device. When used in a WAN-networking environment, the 
computer 20 typically includes a modem 54, a type of communications device, or 
any other type of communications device for establishing communications over the 
wide area network 52, such as the Internet. The modem 54, which may be internal 

20 or external, is connected to the system bus 23 via the serial port interface 46. In a 
networked environment, program modules depicted relative to the personal 
computer 20, or portions thereof, may be stored in the remote memory storage 
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device. It is appreciated that the network connections shown are exemplary and 
other means of and communications devices for establishing a communications link 
between the computers may be used. 

The hardware and operating environment in conjunction with which 
5 embodiments of the invention may be practiced has been described. The computer 
in conjunction with which embodiments of the invention may be practiced may be a 
conventional computer, a distributed computer, or any other type of computer; the 
invention is not so limited. Such a computer typically includes one or more 
processing units as its processor, and a computer-readable medium such as a 
10 memory. The computer may also include a communications device such as a 
network adapter or a modem, so that it is able to communicatively couple other 
computers. 

One exemplary embodiment of a suitable client computer is described in the 
related application titled "System and Method for Authenticating an Operating 

15 System to a Central Processing Unit, Providing the CPU/OS with Secure Storage, 
and Authenticating the CPU/OS to a Third Party," and illustrated in FIG IB as 
subscriber unit 124. The CPU 140 in the subscriber unit 124 is able to authenticate 
the identity of the boot block and OS components that have been loaded into the 
computer, and to provide quoting and secure storage operations based on this 

20 identity as briefly described next. Full descriptions of various embodiments for the 
subscriber unit 124 are provided in the related application. 

The CPU 140 has a processor 160 and also can have a cryptographic 
accelerator 162. The CPU 140 is capable of performing cryptographic functions, 
such as signing, encrypting, decrypting, and authenticating, with or without the 
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accelerator 162 assisting in intensive mathematical computations commonly 
involved in cryptographic functions. 

The CPU manufacturer equips the CPU 140 with a pair of public and private 
keys 164 that is unique to the CPU. For discussion purpose, the CPU's public key 
5 is referred to as "Kcpu" and the corresponding private key is referred to as "Kcpu" 1 " 
Other physical implementations may include storing the key on an external device 
to which the main CPU has privileged access (where the stored secrets are 
inaccessible to arbitrary application or operating systems code). The private key is 
never revealed and is used only for the specific purpose of signing stylized 
10 statements, such as when responding to challenges from a content provider, as is 
discussed below. 

The manufacturer also issues a signed certificate 166 testifying that it 
produced the CPU according to a known specification. Generally, the certificate 
testifies that the manufacturer created the key pair 164, placed the key pair onto the 

15 CPU 140, and then destroyed its own knowledge of the private key "Kcpu" 1 ". In 
this way, only the CPU knows the CPU private key Kcpu" 1 ; the same key is not 
issued to other CPUs and the manufacturer keeps no record of it. The certificate 
can in principle be stored on a separate physical device associated with the 
processor but still logically belongs to the processor with the corresponding key. 

20 The manufacturer has a pair of public and private signing keys, K MFR and 

Kmfr" 1 . The private key Kmfr" 1 is known only to the manufacturer, while the public 
key Kmfr is made available to the public. The manufacturer certificate 166 contains 
the manufacturer's public key Kmfr* the CPU's public key Kcpu, and the above 
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testimony. The manufacturer signs the certificate using its private signing key, 
Kmfr" 1 ,^ follows: 

Mfr. Certificate = (Kmfr> Certifies-for-Boot, Ka>u), signed by Kmfr 1 
The predicate "certifies-for-boot" is a pledge by the manufacturer that it 
5 created the CPU and the CPU key pair according to a known specification. The 
pledge further states that the CPU can correctly perform authenticated boot 
procedures, as are described below in more detail. The manufacturer certificate 166 
is publicly accessible, yet it cannot be forged without knowledge of the 
manufacturer's private key Kmfr" 1 . 

10 A chain of certificates can be extended from the manufacturer's 

certificate using intermediate certificates and additional key pairs. When 
verification is performed using an intermediate certificate in the chain instead of the 
manufacturer's certificate, the frequency of use of the important "root" key pairs, 
Kcpu /Kcpu 1 m ^ K M fr/Kmfr"\ * s P eaj ^y reduced and hence the root keys are less 

1 5 likely to be stolen. 

The CPU 140 has an internal software identity register (SIR) 168, which 
contains the identity of an authenticated operating system 180 or a predetermined 
false value (e.g., zero) if the CPU determines that the operating system 180 cannot 
be authenticated. The operating system (OS) 180 is stored in the memory 142 and 

20 executed on the CPU 140. The operating system 180 has a block of code 182 that is 
used to authenticate the operating system to the CPU during the boot operation. 
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The boot block 182 uniquely determines the operating system, or class of operating 
systems (e.g. those signed by the same manufacturer). 

System Level Overview 
5 A system level overview of the operation of an exemplary embodiment of 

the invention is described by reference to FIG. 2. A subscriber computer 200, such 
as client computer 20 in FIG.1A, is connected to a content provider server computer 
220, such as remote computer 49, through a wide-area network, such as WAN 52. 
Processes performed by the components of the subscriber computer 200 and the 

10 content provider 220 are illustrated by arrows in FIG. 2. Many of these processes 
incorporate either public/private key pairs, digital signatures, digital certificates, 
and/or encryption algorithms, or a combination of these standard cryptographic 
functions. Such functions are assumed to be provided by the CPU of the subscriber 
computer in the descriptions that follow, but can be provided by other well-known 

15 cryptographic mechanisms as will be immediately understood by one skilled in the 
art 

In the exemplary embodiment illustrated in FIG. 2, component certificates 
and boot certificates are used in combination to prove the identity of an operating 
system executing on the subscriber computer 200 to the content provider 220. Each 
20 component certificate is published and signed by a boot authority, using a private 
key, to indicate that the boot authority attests to the validity and security of the 
corresponding component. Each boot authority also publishes a boot certificate that 
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contains the public key necessary to verify the signature on the component 
certificate. When the client computer 200 is booted, a particular combination of 
boot authorities is chosen to verify the loaded components. Only two component 
certificates and two boot certificates are shown in FIG. 2 for the sake of clarity in 
5 the following discussion. One of skill in the art will readily recognize that, in 
practice, more than two component certificates will be typically used, and that a 
different number of boot certificates is equally applicable 

The boot block (the basic components) for the operating system 211 is 
associated with component certificate 205, which is signed by the operating system 

10 vendor and verified using a boot certificate 201 published by the vendor. An 
additional software component, such as a hardware device driver, required to 
operate the computer 200 is associated with component certificate 207. The 
software component's component certificate 207 is signed by an independent boot 
authority and verified using the boot certificate 203 published by the independent 

15 boot authority. 

When the client computer 200 is booted, a boot loader 209 for the operating 
system 211 verifies the component certificate for each component to be loaded 
against the boot certificates 201, 203. The identity for the resulting operating 
system 21 1 is a cryptographic digest of the combination of the boot block and the 

20 boot certificates 201, 203, and is recorded in an internal software identity register 
(SIR) 213, as explained previously for SIR 168 in FIG. IB. If a component that 
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cannot be verified is loaded, the identity is set to a default value indicating an 
unverified operating system. 

When the subscriber computer 200 requests download of content 221 from 
provider 220, the content provider 220 transmits a challenge message ("nonce") to 
5 the subscriber computer 200 requesting the boot certificates used to verify the 
components of the current operating system 211. The subscriber computer 200 
transmits an authentication message containing the boot certificates 201, 203, the 
current value of the SIR 213, and the nonce. The subscriber computer attests to the 
identity in the SIR 213 by signing the value with the private key of its CPU. 

10 The content provider 220 examines the certificates 201, 203 and the identity 

to determine whether it should establish a trust relationship with the subscriber 
computer 200. If so, the content provider 220 downloads the content to the 
subscriber computer 200. If the content is to be permanently stored on the 
subscriber computer 200, the operating system 211 writes the content to a storage 

15 device 215 and keys the access of the stored content, or "secret," 217 to the identity 
to prevent unauthorized access to the content. Device 215 is illustrated in FIG. 2 as 
a disk drive but such illustration is not intended to limit the range of devices that 
can serve as secured storage. 

In an exemplary embodiment, each component certificate is valid for a finite 

20 period of time, and each boot certificate has an issue date. The interaction between 
the certificates is based on relative dates as illustrated using a time line in FIG. 3. 
Boot certificate 301 has an issue date of time mark 1 and boot certificate 302 has an 
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issue date of time mark 4. Component certificate 303 expires at time mark 5, 
component certificate 304 at time mark 3, component certificate 305 at time mark 2, 
and component certificate 306 at time mark 6. When the subscriber computer 200 
is booted any time between time marks 1 and 4, it checks the expiration dates of 
5 each component certificate for a component to be loaded against the issue date of 
the boot certificate. As long as the component certificate is valid as of the issue 
date, the component will be loaded. Thus, the components associated with 
component certificates 303, 304, 305, 306 are always loaded when using boot 
certificate 301 and the computer will always be able to be booted into a verified 

10 operating system. 

When booting with boot certificate 302, however, the components associated 
with component certificates 304, 305 cannot be verified since their valid periods 
have expired before the issue date of boot certificate 302. If these components must 
be loaded, the identity of the operating system is set to the value for an unverified 

15 operating system. New component certificates are required to load the components 
in a verified operating system under the boot certificate 302. The process of 
obtaining a new component certificate is handled automatically by the operating 
system and is described in the next section. 

Because a particular version of a component can be discovered to 

20 have a vulnerability before the expiration date of its associated component 
certificate, an alternate embodiment of the invention associates a revocation list 
with each boot certificate. If a component appears in the revocation list, the boot 
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certificate will not verify the component until an updated version of the component 
is obtained. As before, if an unverified component is loaded, the identity is set to 
the unverified value. In one embodiment, the revocation list also contains an on- 
line address (URL) for the updated version of the component so the operating 
5 system can automatically obtain the new version as described in the next section. 
One exemplary embodiment of a revocation list in which each vulnerable 
component is identified by its name and version or by its cryptographic digest is 
described in further detail below. 

If the content provider refuses to download content because one or 

10 more of the boot certificates are considered out-dated, the current operating system 
can obtain later-issued boot certificates to be used on subsequent boots under the 
newer boot certificates. Because existing content is secured through the identity of 
the operating system, booting with the new boot certificates will cause that content 
to be inaccessible. Therefore, the current operating system re-stores the content 

15 using the new identity before the system is rebooted. The process of obtaining 
later-issued boot certificates and re-securing content is also described in the next 
section. 

The system level overview of the operation of an exemplary 
embodiment of the invention has been described in this section of the detailed 
20 description. A boot domain is created on a client, subscriber computer, which is 
defined by boot certificates, component certificates, and stored secrets. Software 
components to be loaded in the subscriber computer are verified using the 
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certificates in accordance with specified boot rules. An operating system identity is 
created that reflects the boot certificates used to verify the components. A content 
provider determines whether to trust the operating system based on the operating 
system identity and the boot certificates. While the invention is not limited to any 
5 particular combination of boot and component certificates, for sake of clarity a 
simplified operating system using two boot certificates and two component 
certificates has been described. 

Methods of an Exemplary Embodiment of the Invention 
10 In the previous section, a system level overview of the operation of an 

exemplary embodiment of the invention was described. In this section, the 
particular methods performed by the client, or subscriber computer, of such an 
exemplary embodiment are described by reference to a series of flowcharts. The 
methods to be performed by the clients constitute computer programs made up of 
15 computer-executable instructions. Describing the methods by reference to a 
flowchart enables one skilled in the art to develop such programs including such 
instructions to carry out the methods on suitable computerized clients (the processor 
of the clients executing the instructions from computer-readable media). 

Referring first to FIG. 4, a flowchart of a method to be performed by a 
20 subscriber computer, according to an exemplary embodiment of the invention is 
shown. This method is inclusive of the acts required to be taken as part of the boot 
process. When the boot process begins, a boot manager presents the user with a 



WO 01/42889 PCT/US00/42678 

19 

choice of boot certificates that can be used to verify the operating system 
components (block 401). The user chooses the desired boot certificate or 
certificates, and the boot loader creates the verified operating system identity based 
on the boot block and the chosen boot certificates (block 403). Each component that 
5 is to be loaded is verified by comparing its component certificate against one of the 
boot certificates (block 405). The verification process checks the signature on the 
component certificate (block 407), the expiration date of the component certificate 
(block 409), and the revocation list (block 411) to determine if the component can 
be loaded. If the component certificate passes all three tests, i.e., satisfies the boot 

10 rules, then the corresponding component is loaded (block 413). 

If the component certificate fails to satisfy one of the boot rules, the boot 
loader presents the user with the choice of loading the corresponding component 
and booting into an unverified operating system, or not loading the component 
(block 415). If the component is required, the boot loader sets the identity of the 

15 operating system to a value indicating an unverified operating system (block 417) 
and loads the component (block 413). If the user chooses not to load the 
component, the verified identity is preserved. 

The boot process proceeds according to the boot rules until all components 
have been loaded (block 419). 

20 When the operating system is completely booted, if one or more of the 

components could not be verified the user is given the opportunity to obtain either 
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valid component certificates or updated components as illustrated in FIGs. 5 and 6, 
respectively. 

If the component certificate has expired and the user chooses get a new 
certificate (block 501 in FIG. 5), the operating system requests the new component 
5 certificate from the boot authority that signed the expired certificate (block 503). 
Upon receipt, the new component certificate is stored in place of the expired 
certificate (block 505) for use upon subsequent boots. 

If the version of the component is listed in the revocation list and the user 
chooses to obtain an updated version (block 601 in FIG. 6), the operating system 

10 requests the updated version from a download site associated with the component 
(block 603). In one embodiment, the URL for the site is stored in the revocation 
list. A new component certificate for the updated version is also downloaded. The 
updated component and new component certificate are stored for verification and 
loading upon the next boot (block 605). 

15 FIGs. 7A and 7B illustrate the processes performed by the subscriber 

computer in requesting content from a provider. The subscriber computer sends a 
request message to the provider (block 701) and receives a challenge nonce in 
response (block 703). The subscriber computer sends an authentication message 
containing the boot certificate^), the operating system identity, and the nonce back 

20 to the provider (block 705). 

If the provider trusts the operating system based on the boot certificate^) 
and operating system identity (block 707), it downloads the content to the 
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subscriber computer (block 709), which secures the content on permanent storage 
based on the operating system identity (block 711). 

If the provider determines that the boot certificate^) used to verify the 
components are out-dated, the subscriber computer presents the user with the 
5 opportunity to obtain newer boot certificate(s) (block 713). The subscriber 
computer requests the newer boot certificate(s) from the corresponding boot 
authorities (block 715) and stores the new boot certificates without overwriting the 
older versions (block 717). 

The current operating system determines if the operating system defined by 
10 the new boot certificate(s) will boot by verifying each component certificate signed 
by the boot authorities that published the new boot certificate(s) (block 719). The 
new operating system can fail because one or more of the component certificates 
have expired when compared to the new boot certificate^) (block 735), or because 
one or more of the components are versions listed in the revocation list associated 
15 with the new boot certificate^) (block 737). New component certificates are 
obtained using the process described above in conjunction with FIG. 5; updated 
components are obtained using the process described above in conjunction with 
FIG. 6. 

When the current operating system determines the new operating system will 
20 boot, it creates a new operating system identity based on the new boot component(s) 
(block 721). Because each operating system identity controls the secrets in the 
associated boot domain, a new boot domain must be created for the new operating 
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system identity. Each secret is evaluated to determine if it will be part of the new 
boot domain (block 723). Three rules govern the choice of secrets for the new boot 
domain: the new boot certificate^) must be from the boot authorities as the current 
boot certificate(s) (block 725), the new boot certificate(s) must be issued after the 
5 current boot certificate(s) (block 727), and the content must not have not expired 
before the issue date of the new boot certificate(s) (block 729). A qualifying secret 
is unsealed using the current operating system identity, a copy made of the content, 
and the copy is re-sealed using the new operating system identity (block 731). The 
process continues until all appropriate secrets have been sealed in the new boot 

10 domain (block 733). The next time the subscriber computer is booted under the 
particular boot certificate combination, the new boot certificate(s) will take effect 
and the secrets in the new boot domain will be accessible. One of skill in the art 
will readily appreciate that this procedure can be automated as part of the normal 
operating system update process, 

15 in one embodiment, the secrets in the old boot domain are deleted upon the 

first successful boot under the new boot certificate(s). In an alternate embodiment, 
only expired content is deleted. 

The particular methods performed by a client of an exemplary embodiment 
of the invention have been described. The method performed by the client 

20 computer has been shown by reference to flowcharts including all the acts from 400 
until 417, from 501 until 505, from 601 until 605, and from 701 until 737. 
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1. Microsoft "WINDOWS" Implementation 

In this section of the detailed description, a particular implementation of the 
invention is described for the Microsoft Corporation "WINDOWS" family of 
operating systems. Microsoft acts as a boot authority by publishing boot certificates 
5 and component certificates for the boot blocks of the various versions of the 
"WINDOWS" operating system. The "WINDOWS" operating system boot 
manager and boot loader are extended to operate according to the methods 
described in the previous section. Exemplary embodiments of a boot certificate and 
a component certificate for use in the "WINDOWS" operating system 

10 implementation are illustrated in FIGs. 8A and 9, respectively. An exemplary 
embodiment of a revocation list entry is illustrated in FIG. 8B. An exemplary 
embodiment of an additional certificate, a time certificate, is illustrated in FIG. 10. 

Turning first to FIG. 8A, the exemplary embodiment of the boot certificate 
800 comprises five constant fields and three optional fields. The constant fields 

15 contain an identifier 801 for the boot authority, the issue date 802 of the certificate, 
the digest 803 of the certificate, the public key 804 of the boot authority, and the 
digital signature 808 of the boot authority that issued the certificate 800, ie., the 
boot authority identified by field 801. The public key 804 is used to verify the 
digital signature 808 on the boot certificate 800 as well as being used to verify the 

20 component certificates signed by the same boot authority. 

In one embodiment, the boot certificate 800 includes an expiration date 80S 
for the boot certificate. The "WINDOWS" operating system uses the expiration 
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date 805 to determine when a new boot certificate is required, without having to be 
so informed by a content provider. 

In an alternate embodiment, the boot certificate 800 includes a revocation list 
806. The function of the revocation list has been described in the previous sections. 
5 An exemplary embodiment of an entry in the revocation list 806 is illustrated in 
FIG. 8B. Each entry 810 comprises the name and version 81 1 of the component 
that is revoked, a cryptographic digest 812 of the revoked component, and a URL 
813 for a download site containing an updated version of the component. 

In still another embodiment, the boot certificate 800 includes boot rules 807 
10 in the form of a command script that is executed by the boot process before loading 
each component signed by the boot authority identified by field 801. In yet another 
alternate embodiment, the boot rules 807 are a series of operating system 
commands. 

The exemplary embodiment of the component certificate shown in FIG. 9 is 
15 implemented by all boot authorities that attest to components for loading in a 
"WINDOWS" operating system. The component certificate 900 contains the 
identity 901 of the boot authority, the name and version 902 of the corresponding 
component, the digest 903 of the component, the issue date 904 of the component 
certificate, the expiration date 904 of the certificate, and the digital signature 906 of 
20 the boot authority. The public key in the boot certificate 800 for the boot authority 
is used to verify the digital signature 906 of the component certificate. 
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When the boot certificate 800 contains a revocation list 806, the 
"WINDOWS" operating system compares name and version 902 and digest 903 in 
the component certificate against each entry 810 in the revocation list 806 to 
determine if the component has been revoked. If the component has been revoked, 
5 a new version is obtained from the URL address in the entry 810 when the user so 
chooses. 

The "WINDOWS" operating system implementation also uses a time 
certificate that enables the setting of time limits on content that is of shorter 
duration than is possible using only the boot certificates. The exemplary 

10 embodiment of a time certificate 1000 shown in FIG. 10 contains the same constant 
fields as the boot certificate 800, except that the time certificate contains an issue 
time as well as an issue date 1002. The time certificate 1000 is folded into the 
operating system identity along with the boot certificate(s), and is sent to the 
content provider as part of the authentication message. Use of the time certificate 

15 1000 is equivalent to an attestation by the "WINDOWS" operating system that the 
computer was booted at a date and time after the issue date and time 1002. 

Before downloading quickly expiring content, the content provider 
determines if the current time certificate, if any, is too old. If so, or if there is no 
current time certificate, the subscriber computer must acquire a new time certificate 
20 and reboot under an operating system identity that includes the new time certificate. 
Because the time certificate is part of the operating system identity, secrets sealed 
under the old identity must be evaluated for copying into the new boot domain as 
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described in the previous section for boot certificates. In this case, the expiration of 
existing content is determined based on the issue date and time of the time 
certificate. Additionally, any expired content is deleted when the new operating 
system identity becomes effective. 

5 

Conclusion 

Client boot domains and boot rules have been described. Although specific 
embodiments have been illustrated and described herein, it will be appreciated by 
those of ordinary skill in the art that any arrangement which is calculated to achieve 
10 the same purpose may be substituted for the specific embodiments shown. This 
application is intended to cover any adaptations or variations of the present 
invention. 

For example, those of ordinary skill within the art will appreciate that any 
organization can act as a boot authority. It is solely the decision of each individual 
15 content provider as to which boot authorities it trusts. Furthermore, those of 
ordinary skill within the art will appreciate that a component certificate will 
typically have a shorter validity period than a boot certificate since changing 
versions of a boot certificate requires unsealing and resealing all secrets in the boot 
domain. 

20 In addition, although the invention has been described in terms of loading an 

operating system as a result of powering on a computer, one of skill in the art will 
recognize that the invention can be used to load an operating system under the 
control of an already-executing operating system, or to load an operating system 
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into a protected address space on a computer running an unverified operating 
system. 

The terminology used in this application with respect is meant to include all operating 
system environments in which different software components must be loaded in order 
5 for the computer to function. 



28 



1. CLAIMS 

1. A computerized method for establishing a boot domain on a client 
5 computer comprising: 

selecting a boot certificate associated with the boot domain; 
creating a verified operating system identity from the boot certificate; 

and 

loading each one of a plurality of operating system components in 
10 accordance with a set of boot rules based on the boot certificate. 

2. The method of claim 1, further comprising: 

creating an unverified operating system identity when one of the 
plurality of operating system components fails the set of boot rules. 

15 

3. The method of claim 1, wherein each of the plurality of operating 
system components is associated with a component certificate and the set of boot 
rules comprises: 

verifying that each component certificate is signed by a boot authority 
20 that issued the boot certificate; 

verifying that each component certificate is valid as of an issue date 
for the boot certificate; and 
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verifying that each component is not listed in a revocation list 



associated with the boot certificate. 



4. 



The method of claim 3, further comprising: 



5 



obtaining a new component certificate to replace an component 



certificate that is expired as of the issue date of the boot certificate. 

5. The method of claim 3, further comprising: 

obtaining a new component to replace a component that is listed in 
10 the revocation list associated with the boot certificate; and 

obtaining the associated component certificate for the new 

component 



6. 



The method of claim 1, further comprising: 



15 



securing data for use in the boot domain using a key based on the 



verified identity of the operating system. 



7. 



The method of claim 6, further comprising: 



obtaining a new boot certificate; 



20 



creating a new verified operating system identity from the new boot 



certificate; and 
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re-securing the data in the boot domain with the new verified 
operating system identity. 

8. The method of claim 6, wherein re-securing the data in the boot 
5 domain comprising: 

verifying that the new boot certificate is issued by a boot authority 
that is the same as the boot authority that issued the boot certificate; 

verifying that the new boot certificate is issued at a later date than the 
boot certificate; 

10 verifying that the data in the boot domain has not expired; 

unsealing the data in the boot domain with the verified operating 
system identity; 

copying the data; and 

sealing the copy of the data with the new verified operating system 

15 identity. 

9. The method of claim 1 , wherein the actions are performed in the order 
recited. 



20 10. A computer-readable medium having stored thereon a boot certificate 

data structure comprising: 
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a boot authority field containing data representing an identifier for a 
boot authority that published the boot certificate; 

an issue date field containing data representing a date when the boot 
authority identified by the boot authority field published the boot certificate; 



authority identified by the boot authority field; 

a certificate digest field containing data representing a cryptographic 
hash of the boot authority field, the issue data field, and the public key field; and 

a signature field containing data representing a digital signature for 
10 the boot authority identified by the boot authority field. 

1 1 . The computer-readable medium of claim 1 0, further comprising: 

an expiration date field containing data representing a date when the 
boot authority identified by the boot authority field invalidates the boot certificate. 



12. The computer-readable medium of claim 10, further comprising: 

a revocation list field containing data representing a list of software 
components no longer attested to by the boot authority identified by the boot 
authority field. 



a public key field containing representing a public key for the boot 
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13. The computer-readable medium of claim 11, wherein the revocation 
list field further comprising a plurality of revocation list entries, each revocation list 
entry comprising: 

a component field containing data representing a version of a 
5 software component; 

a component digest field containing data representing a cryptographic 
hash of the software component identified by the component field; and 

an address field containing data representing an on-line source having 
a later version of the component identified by the component field. 

10 

14. The computer-readable medium of claim 10, further comprising: 

a boot rules field containing data representing a set of rules required 
by the boot authority identified by the boot authority field, wherein the set of rules 
direct the booting of a computer under the boot certificate. 



15 



15. The computer-readable medium of claim 14, wherein the set of rules 
are a series of operating system commands. 



16. The computer-readable medium of claim 14, wherein the set of rules 
20 are in a operating system script language. 
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17. A computer-readable medium having stored thereon a component 
certificate data structure, the component certificate data structure associated with a 
software component, comprising: 

a boot authority field containing data representing an identifier for a 
5 boot authority that published the component certificate; 

a component field containing data representing a version for the 
software component attested to by the boot authority identified by the boot authority 
field; 

a component digest field containing data representing a cryptographic 
1 0 hash of the software component identified by the component field 

an issue date field containing data representing a date when the boot 
authority identified by the boot authority field published the component certificate; 

an expiration date field containing data representing a date when the 
boot authority identified by the boot authority field invalidates the component 
15 certificate; and 

a signature field containing data representing a digital signature for 
the boot authority identified by the boot authority field. 

18. A computer-readable medium having stored thereon a time certificate 
20 data structure comprising: 

a time authority field containing data representing an identifier for a 
time authority that published the time certificate; 
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an issue date and time field containing data representing a date and 
time when the time authority identified by the time authority field published the 
time certificate; 

a public key field containing representing a public key for the time 
5 authority identified by the time authority field; 

a certificate digest field containing data representing a cryptographic 
hash of the time authority field, the issue data field, and the public key field; and 

a signature field containing data representing a digital signature for 
the time authority identified by the time authority field. 

10 

19. A computerized system comprising: 
a processing unit; 

a system memory coupled to the processing unit through a system 

bus; 

15 a computer-readable medium coupled to the processing unit through a 

system bus; and 

a boot manager executed from the computer-readable medium by the 
processing unit, wherein the boot manager causes the processing unit to request a 
boot certificate selection from a user of the computerized system. 

20 

20. The computerized system of claim 1 9, further comprising: 
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a boot loader executed from the computer-readable medium by the 
processing unit, wherein the boot loader causes the processing unit to boot 
subsequent software components based on a set of boot rules for the boot 
certificate. 

21. The computerized system of claim 20, wherein the boot loader further 
causes the processing unit to create a verified operating system identity from the 
boot certificate when the boot rules are satisfied. 

22. The computerized system of claim 21, further comprising: 

a wide area network connection coupled to the processing unit; and 
a verified operating system booted in accordance with the boot rules, 
wherein the verified operating system causes the processing unit to transmit the 
verified operating system identity and the boot certificate to a server computer. 

23. The computerized system of claim 22, wherein the verified operating 
system further causes the processing unit to secure data downloaded from the server 
computer through the verified operating system identity. 

23. The computerized system of claim 23, wherein the verified operating 
system further causes the processing unit to obtain a new boot certificate, to create a 
new verified operating system identity from the new boot certificate, and to unseal 
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downloaded data secured with the verified operating system identity, and further to 
re-seal the downloaded data through the new 
verified operating system identity. 

5 24. A computer-readable medium having computer-executable modules 

stored thereon, the modules comprising: 

a boot manager for determining a boot certificate associated with one 
of a plurality of boot domains; and 

a boot loader for loading each one of a plurality of operating system 
10 components in accordance with a set of boot rules for the boot certificate and 
further for creating a verified operating system identity from the boot certificate. 



25. The computer-readable medium of claim 24, further comprising: 

the plurality of operating system components for creating a verified 
15 operating system associated with the boot domain. 

26. The computer-readable medium of claim 24, wherein the boot 
manager determines the boot certificate based on user input. 



20 



27. The computer-readable medium of claim 24, wherein the boot loader 
further creates an unverified operating system identify when one of the plurality of 
operating system components fails the set of boot rules. 
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28. A method of transferring data between a client and a server computer 
comprising: 

obtaining, by the client computer, a boot certificate; 
5 loading, by the client computer, a plurality of operating system 

components as specified by the boot certificate to boot a verified operating system 
on the client computer; 

creating, by the client computer, a verified operating system identity 
for the verified operating system from the boot certificate; 
10 transmitting, by the client computer, the verified operating system 

identity and the boot certificate to the server computer; 

determining, by the server computer, what data is available to the 
client computer based on the verified operating system identity and the boot 
certificate; 

15 downloading, by the server computer, the available data to the client 

computer; and 

securing, by the client computer, the downloaded data on the client 
computer through the verified operating system identity. 

20 29. The method of claim 28, wherein loading the plurality of operating 

system components is performed under the control of a different operating system. 
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30. The method of claim 28, wherein the plurality of operating system 
components is loaded into a protected address space. 

31. A computer-readable medium having computer-executable 
5 instructions stored thereon to establish a boot domain on a computer, the 

instructions comprising: 

obtaining a boot certificate associated with the boot domain; and 
booting an operating system specified in the boot certificate. 

10 32. The computer-readable medium of claim 3 1 , further comprising; 

creating a verified operating system identity from the boot certificate. 

33. The computer-readable medium of claim 31, wherein booting the 
operating system comprises: 
15 determining a set of boot rules associated with the boot certificate; 

and 

evaluating each one of a plurality of components for the operating 
system for compliance with the boot rules. 



20 



34. The computer-readable medium of claim 33, further comprising: 
loading each one of the plurality of components that is in compliance 
with the boot rules. 
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35. The computer-readable medium of claim 33, further comprising: 
loading each one of the plurality of components; and 
creating an unverified operating system identity when one of the 
5 plurality of components is not in compliance with the boot rules. 
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